\documentclass[a4paper,12pt]{article}
\usepackage{fancyhdr}
\usepackage[MeX]{polski}
\usepackage[utf8]{inputenc}
\usepackage{amsmath,amsthm,amssymb}
\usepackage{graphicx}

\usepackage[lmargin=2.7cm]{geometry}

\pagestyle{fancy}
\lhead{IT Service Continuity Management -- Dokument wizji}
\rhead{\bfseries}



\author{Adrian Chudziński, Przemysław Gospodarczyk, Łukasz Synówka}
\title{IT Service Continuity Management -- Dokument wizji}

\begin{document}

\makeatletter
    \renewcommand\@seccntformat[1]{\csname the#1\endcsname.\quad}
    \renewcommand\numberline[1]{#1.\hskip0.7em}
\makeatother

\begin{titlepage}
\begin{center}

    \textsc{ITIL -- najlepsze praktyki IT}\\[0.1cm]
    \textsc{IIUWr 2009/2010}\\[6cm]
    Adrian Chudziński, Przemysław Gospodarczyk, Łukasz Synówka\\[1cm]
    \textsc{\Large IT Service Continuity Management}\\[0.25cm]
    \textsc{\large Dokument wizji}\\[7.675cm]

    {\footnotesize
    \begin{tabular}{| c | p{4cm} | p{4.25cm} | c | }
        \hline
        Wersja  &
        Zmiany  &
        Autorzy &
        Data    \\
        \hline
        1.0                                                                   &
        Pierwsza wersja                                                       &
        \par Adrian Chudziński \par Przemysław Gospodarczyk \par Łukasz Synówka                                       &
        2010-04-05                                                            \\
        \hline
        2.0                                                                   &
        Druga wersja                                                       &
        \par Adrian Chudziński \par Przemysław Gospodarczyk \par Łukasz Synówka                                       &
        2010-06-14                                                           \\
        \hline
    \end{tabular}
    }

\end{center}
\end{titlepage}

\break

\setcounter{page}{2}

\tableofcontents

\break

\section[Wprowadzenie]{Wprowadzenie}

Aplikacja SCM umożliwia efektywne reagowanie w sytuacjach kryzysowych mogących pojawić się podczas pracy nadzorowanych systemów. Aplikacja pozwala na definiowanie procedur awaryjnych oraz wspomaga ich testowanie.

Postęp prac nad projektem można obserwować na stronie projektu:\newline

http://code.google.com/p/itil-scm/.

\section[Opis użytkownika]{Opis użytkownika}
Użytkownikami systemu są pracownicy firmy. Mają oni za zadanie kontrolować, monitorować dany system, a w razie awarii wysyłanie odpowiednich komunikatów i oczekiwanie na odpowiedz.
\subsection[Administrowanie]{Administrowanie}
	Zadanie administratora jest zapewnienie prawidłowego działania systemu. Jego zadaniem jest dbanie o odpowiednią konfigurację.	 Administrator ma możliwość zmiany dostępu do aplikacji. Powinien też kontrolować, w jaki sposób korzystają z niego inni użytkownicy. Powinien mieć wygląd do listy nowo zarejestrowanych użytkowników. Powinni móc przeglądać listę aktualnie zalogowanych osób jak i historie logowania.
\subsection[Obsługa zgłoszeń]{Obsługa zgłoszeń}
	Do obsługi systemu potrzebna jest grupa osób zajmująca się monitorowaniem i obsługą zgłoszeń. Osoby te mają za zadanie wychwytywanie błędów i klasyfikowanie ich. Do ich zadań należy również wykonywanie testów monitorowanych systemów oraz wykonywanie procedur. Użytkownicy sami definiują procedury, mogą je też usuwać. Ważnym zadaniem jest testowanie procedur.
\subsection[Przesyłanie informacji]{Przesyłanie informacji}
	Ta grupa zajmuje się wysyłaniem powiadomień i odbieraniem informacji o naprawieniu awarii. Zadaniem tej grupy jest również wysłanie informacji o naprawieniu usterki i możliwości wznowienia pracy. Odbiorcy mają możliwość odbierania wiadomości tekstowych za pomocą aplikacji.
	
\section[Ogólny opis produktu]{Ogólny opis produktu}

Aplikacja skierowana jest do firm posiadających działy IT zajmujące się zapewnianiem ciągłości działania systemów w sytuacjach kryzysowych.

Główny cel stawiany aplikacji to pomoc w efektywnym reagowaniu na sytuacje kryzysowe mogące zdarzyć się w trakcie działania nadzorowanego systemu. Cel ten będzie realizowany poprzez umożliwienie użytkownikom definiowania procedur awaryjnych wykonywanych w momencie zaistnienia określonych sytuacji. Część procedur będzie uruchamiana automatycznie na podstawie danych otrzymanych z czujników, co pozwoli maksymalnie skrócić czas potrzebny na przywrócenie prawidłowej pracy systemu.

Ważnym aspektem dodatkowym będzie monitorowanie i zapisywanie przebiegu reakcji systemu na sytuacje kryzysowe, aby możliwa była późniejsza analiza tych danych w celu polepszenia jakości świadczonych usług.

Do prawidłowego działania aplikacja wymaga wdrożenia IT Service Availability Management.

\section[Cechy i atrybuty cech produktu]{Cechy i atrybuty cech produktu}
Poniżej przedstawiam cechy aplikacji i ich priorytety.\newline
Skala priorytetów jest 3-stopniowa:
\begin{itemize}
\item[--] wysoki -- aplikacja musi spełniać ustalone wymagania;
\item[--] średni -- dobrze by było, aby aplikacja spełniała wymagania;
\item[--] niski -- aplikacja spełni ustalone wymagania, jeżeli programistom starczy czasu na implementację.
\end{itemize}

\subsection[Aplikacja w języku Java]{Aplikacja w języku Java}
Aplikacja będzie napisana w obiektowym języku Java. Java jest językiem tworzenia programów kompilowanych do kodu bajtowego, który jest wykonywany przez maszynę wirtualną Javy. Programiści wybrali Javę, ponieważ jest to obecnie najpopularniejszy, nowoczesny język programowania z wieloma dodatkowymi bibliotekami, które ułatwiają implementację i dają dużą swobodę przy projektowaniu aplikacji. Ponadto na uwagę zasługuje również fakt, że aplikacje napisane w języku Java uruchamiają się na wielu platformach z różnymi systemami operacyjnymi. \newline
Priorytet cechy jest \textbf{wysoki}.

\subsection[Aplikacja sieciowa]{Aplikacja sieciowa}
System będzie wykorzystywał sieć Internet do komunikacji z użytkownikami.
Aplikacja przesyła odpowiednie wiadomości komunikatorem internetowym lub przez pocztę elektroniczną ustalonym osobom w określonych przypadkach kryzysowych. System czeka na odpowiedź użytkownika, a więc dostępna jest pełna iterakcja z użytkownikiem.\newline
Priorytet cechy jest \textbf{wysoki}.

\subsection[Aplikacja wielowątkowa]{Aplikacja wielowątkowa}
System może być aplikacją wielowątkową, co znacznie usprawni działanie monitora i pozwoli na wychwytywanie wielu usterek na raz. Każdy działający czujnik może być monitorowany przez osobny wątek, co pozwoli dokładnie diagnozować nawet najrozleglejsze awarie monitorowanego systemu. \newline
Priorytet cechy jest \textbf{średni}.

\subsection[Implementacja czujników]{Implementacja czujników}
System powinien implementować podstawowe czujniki programowe, które będą monitorować dany proces (stan konkretnej usługi) i przesyłać informacje na jego temat do systemu. System będzie odpowiednio interpretował przesłane raporty opierając się na określonych parametrach i dozwolonych przedziałach wartości dla tych parametrów. Wartości nie mieszczące  się w określonych przedziałach będą prowadziły do sytuacji kryzysowych.

\par System może również implementować analogiczne czujniki dla sprzętu, co stanowi znacznie większe wyzwanie dla programistów i wymaga współpracy ze sterownikami sprzętowymi. Ponadto należy ustalić konkretny sprzęt (z dokładnością do modelu i wersji sterowników), który miałby być monitorowany.

\noindent Priorytet czujników programowych jest \textbf{wysoki}.\newline
Priorytet czujników sprzętowych jest \textbf{niski}.

\subsection[Wysyłanie powiadomień SMS]{Wysyłanie powiadomień SMS}
System może wykorzystywać wiadomości SMS do komunikacji z ludźmi.
Aplikacja przesyła odpowiednie wiadomości ustalonym osobom na podane numery telefonów w określonych przypadkach kryzysowych.\newline
Priorytet cechy jest \textbf{średni}.


\section[Podstawowe przypadki użycia]{Podstawowe przypadki użycia}
\subsection[Rejestracja]{Rejestracja}
\noindent Cel:
\par Użytkownik chce założyć konto w systemie.\newline
\noindent Warunek wstępny:
\par Użytkownik musi być pracownikiem firmy korzystającej z systemu.\newline
\noindent Scenariusz:
\begin{itemize}
\item[--] użytkownik wypełnia ankietę podając podstawowe dane osobowe i przekazuje ją administratorowi systemu;
\item[--] administrator systemu dodaje nowe konto do bazy danych systemu z poziomu systemu zarządzania bazą. Od tej pory podczas uwierzytelniania, program poprawnie pobiera dane o koncie użytkownika z bazy danych.
\end{itemize}
\noindent Warunek końcowy poprawnie wykonanej operacji:
\par Użytkownik ma możliwość poprawnego uwierzytelnienia się w systemie i otrzymuje odpowiednie uprawnienia.\newline
\subsection[Uwierzytelnienie]{Uwierzytelnienie}
\noindent Cel:
\par zarejestrowany użytkownik chce uzyskać dostęp do swojego konta.

\noindent Warunek wstępny:
\par użytkownik musi mieć założone konto w systemie.

\noindent Scenariusz główny:
\begin{itemize}
\item[--] użytkownik otwiera aplikację;
\item[--] użytkownik wybiera przycisk logowania;
\item[--] system wyświetla formularz uwierzytelnienia;
\item[--] użytkownik wypełnia poprawnie formularz podając: nazwę użytkownika,
hasło składające się z przynajmniej 8 znaków alfanumerycznych
(system odróznia wielkie i małe litery);
\item[--] użytkownik potwierdza wprowadzone w formularzu dane wciskając przycisk
„Gotowe” lub wciskając na klawiaturze przycisk „Enter”;
\item[--] system pobiera dane z wypełnionego formularza i sprawdza, czy zgadzają
się z informacjami zgromadzonymi w bazie danych;
\item[--] system wyświetla stronę główną uwierzytelnionego użytkownika.
\end{itemize}

\noindent Scenariusze alternatywne:
\begin{itemize}
\item[--] użytkownik może podać nieistniejącą w bazie danych nazwę użytkownika, wtedy system prosi użytkownika o rejestrację wyświetlając odpowiedni komunikat;
\item[--] użytkownik może podać niepoprawne hasło, wtedy
system ponownie wyświetla formularz uwierzytelnienia z dodatkowym
komunikatem o niepoprawnych danych. Przy trzeciej nieudanej próbie
podania poprawnego hasła, system informuje,
że administrator zatelefonuje w najbliższym czasie na podany przy
rejestracji numer telefonu w celu rozwiązania problemu;
- użytkownik może nie podać wszystkich wymaganych danych, wtedy
system ponownie wyświetla formularz uwierzytelnienia z dodatkowym
komunikatem o brakujących danych.
\end{itemize}

\noindent Warunki końcowe poprawnie wykonanej operacji:
\begin{itemize}
\item[--] użytkownik zostaje poprawnie rozpoznany przez system,
\item[--] wyświetla się strona główna konta w systemie.
\end{itemize}

\subsection[Dodawanie nowej procedury]{Dodawanie nowej procedury}
\noindent Cele:
\begin{itemize}
\item[--] możliowość zdefiniowania odpowiedniej procedury w celu ułatwienia zarządzania usługami,
\item[--] możliowość zdefiniowania odpowiedniej procedury w celu zapewnienia ciągłości działania systemu w sytuacjach kryzysowych.
\end{itemize}

\noindent Warunek wstępny:
\par użytkownik musi być uwierzytelniony.
\noindent Scenariusz:
\begin{itemize}
\item[--] użytkownik wybiera przycisk ,,Dodaj nową procedurę'',
\item[--] użytkownik definiuje procedurę wykorzystując listę dostępnych typów zdarzeń i listę dostępnych akcji,
\item[--] użytkownik zatwierdza nową procedurę przyciskiem ,,OK'',
\item[--] system zapisuje do bazy danych informacje o nowej procedurze i wyświetla potwierdzenie poprawności wykonania operacji na ekranie.
\end{itemize}

\noindent Warunek końcowy poprawnie wykonanej operacji:
\par proces testowania procedury przebiega poprawnie.

\subsection[Edycja istniejącej procedury]{Edycja istniejącej procedury}
\noindent Cel:
\par użytkownik chce zmienić zdefiniowaną przez siebie i zatwierdzoną przez system procedurę.

\noindent Warunki wstępne:
\begin{itemize}
\item[--] użytkownik musi być uwierzytelniony;
\item[--] użytkownik musi być autorem procedury, którą chce modyfikować.
\end{itemize}

\noindent Scenariusz:
\begin{itemize}
\item[--] użytkownik wybiera przycisk ,,Edytuj procedurę'',
\item[--] użytkownik wybiera procedurę do zmodyfikowania z listy zdefiniowanych przez niego procedur i wciska przycisk ,,OK'',
\item[--] użytkownik dowolnie modyfikuje listę typów zdarzeń i listę dostępnych akcji, które wykorzystuje procedura,
\item[--] użytkownik zatwierdza nową procedurę przyciskiem ,,OK'',
\item[--] system zapisuje do bazy danych informacje o zmodyfikowanej procedurze i wyświetla potwierdzenie poprawności wykonania operacji na ekranie.
\end{itemize}

\noindent Warunek końcowy poprawnie wykonanej operacji:
\par proces testowania procedury przebiega poprawnie, tzn. zgodnie z dokonaną modyfikacją.

\subsection[Usuwanie procedury]{Usuwanie procedury}
\noindent Cel:
\par użytkownik chce usunąć procedurę, którą sam zdefiniował.

\noindent Warunki wstępne:
\begin{itemize}
\item[--] użytkownik musi być uwierzytelniony;
\item[--] użytkownik musi być autorem procedury, którą chce usunąć.
\end{itemize}

\noindent Scenariusz:
\begin{itemize}
\item[--] użytkownik wybiera przycisk ,,Usuń procedurę'',
\item[--] użytkownik wybiera procedurę do usunięcia z listy zdefiniowanych przez niego procedur i wciska przycisk ,,OK'',
\item[--] system usuwa z bazy danych informacje o procedurze i wyświetla potwierdzenie poprawności wykonania operacji na ekranie.
\end{itemize}

\noindent Warunek końcowy poprawnie wykonanej operacji:
\par system poprawnie usunął z bazy danych informacje o procedurze, nie wyświetla jej na liście zdefiniowanych procedur i nie stosuje jej.

\subsection[Testowanie procedury]{Testowanie procedury}
\noindent Cel:
\par użytkownik chce wytestować poprawność procedury (zdefiniowaną przez siebie lub przez innego użytkownika).

\noindent Warunek wstępny:
\par użytkownik musi być uwierzytelniony.

\noindent Scenariusz główny:
\begin{itemize}
\item[--] użytkownik wybiera przycisk ,,Testuj procedurę'';
\item[--] użytkownik wybiera procedurę do testowania z listy wszystkich procedur zdefiniowanych w systemie i wciska przycisk ,,OK'';
\item[--] użytkownik wybiera akcje wykonywane przez procedurę, które mają zostać wytestowane. Użytkownik może wybrać część zdarzeń i zatwierdzić swój wybór przyciskiem ,,OK'';
\item[--] system poprawnie wykonuje wybrane zdarzenia i wyświetla raport z wykonanego testu.
\end{itemize}

\noindent Scenariusz alternatywny:
\begin{itemize}
\item[--] system nie potrafi poprawnie wykonać wybranych przez użytkownika zdarzeń i wyświetla raport z wykonanego testu;
\item[--] po zatwierdzeniu raportu użytkownik powinien edytować swoją procedurę, której wykonanie się nie powiodło lub zawiadomić o błędzie jej autora.
\end{itemize}

\noindent Warunek końcowy poprawnie wykonanej operacji:
\par system poprawnie wyświetlił raport z testu i trafnie diagnozuje wszystkie nieprawidłowości związane z testowanymi procedurami.

\subsection[Konfiguracja monitora]{Konfiguracja monitora}
\noindent Cele:
\begin{itemize}
\item[--] użytkownik chce określić, kiedy system ma przejść w stan krytyczny, aby system mógł automatycznie zareagować;
\item[--] użytkownik chce, aby wykrywanie usterek i uruchamianie odpowiednich procedur było efektywniejsze i szybsze.
\end{itemize}

\noindent Warunek wstępny:
\par użytkownik musi być uwierzytelniony.

\noindent Scenariusz:
\begin{itemize}
\item[--] użytkownik wybiera przycisk ,,Konfiguruj monitor'';
\item[--] użytkownik definiuje nową reakcję i wciska przycisk ,,OK'';
\item[--] użytkownik definiuje czujnik, który będzie monitorowany przez system i podaje warunki, które muszą zostać spełnione, aby system uznał sytuację za krytyczną i aby doszło do wykonania określonych procedur;
\item[--] użytkownik zatwierdza swój wybór przyciskiem ,,OK'';
\item[--] system zapisuje do bazy danych informacje o nowej konfiguracji monitora i wyświetla potwierdzenie poprawności wykonania operacji na ekranie.
\end{itemize}

\noindent Warunek końcowy poprawnie wykonanej operacji:
\par system poprawnie monitoruje stan zdefiniowanych czujników, bezbłędnie rozpoznaje sytuacje kryzysowe i w odpowiednich sytuacjach bezzwłocznie wykonuje zdefiniowane procedury.

\section[Model konceptualny bazy danych]{Model konceptualny bazy danych}
\subsection[Opis encji]{Opis encji}
\subsubsection[Users]{Users}
Relacja \texttt{users} przechowuje podstawowe informacje o klientach, które są konieczne do prawidłowego działania systemu uwierzytelniania. Relacja zawiera kolejno następujące atrybuty:
\begin{itemize}
    \item[--] identyfikator konta, który jest kluczem publicznym relacji \texttt{users} i jest automatycznie generowany przez sekwencję \texttt{id\_gen} po rejestracji klienta;
    \item[--] unikatową nazwę użytkownika, która jednoznacznie określa klienta w bazie danych;
    \item[--] hasło, które użytkownik podaje podczas rejestracji składające się z co najmniej 6 znaków alfanumerycznych.
\end{itemize}

\subsubsection[Userdata]{Userdata}
Relacja \texttt{userdata} przechowuje dodatkowe informacje o kliencie. Część z nich jest konieczna do prawidłowego działania systemu. Relacja zawiera kolejno następujące atrybuty:
\begin{itemize}
    \item[--] identyfikator konta, który jest kluczem publicznym relacji \texttt{userdata} i jest kluczem obcym z relacji \texttt{user};
    \item[--] nazwisko, które jest polem wymaganym do wypełnienia podczas rejestracji;
    \item[--] imię, które jest polem wymaganym do wypełnienia podczas rejestracji;
    \item[--] miasto, które nie jest polem wymaganym do wypełnienia podczas rejestracji;
    \item[--] kod pocztowy, który nie jest wymaganym polem do wypełnienia podczas rejestracji;
    \item[--] e-mail, który jest polem wymaganym do wypełnienia podczas rejestracji. Poprawność
              tego pola jest sprawdzana na podstawie domeny \texttt{emailtype} opartej na prostym wyrażeniu
              regularnym;
    \item[--] data urodzenia, która nie jest wymaganym polem do wypełnienia podczas rejestracji;
    \item[--] stanowisko, które jest polem wymaganym do wypełnienia podczas rejestracji i może byc jedną z trzech wartości: \texttt{Administrator}, \texttt{Obserwator} lub \texttt{Rozsyłacz}.
\end{itemize}

\subsubsection[Procedures]{Procedures}
Relacja \texttt{procedures} przechowuje informacje o procedurach. Relacja zawiera kolejno następujące atrybuty:
\begin{itemize}
    \item[--] identyfikator procedury, który jest kluczem publicznym relacji \texttt{procedures} i jest automatycznie generowany przez sekwencję \texttt{id\_proc} po dodaniu procedury;
    \item[--] unikatową nazwę procedury, która jednoznacznie określa procedurę w bazie danych;
    \item[--] opis procedury, który może być dowolnej długości;
    \item[--] pole boolowskie przechowujące informację o aktywności procedury.
\end{itemize}

\subsubsection[Actions]{Actions}
Relacja \texttt{actions} przechowuje informacje o akcjach. Relacja zawiera kolejno następujące atrybuty:
\begin{itemize}
    \item[--] identyfikator akcji, który jest kluczem publicznym relacji \texttt{actions} i jest automatycznie generowany przez sekwencję \texttt{id\_act} po dodaniu akcji;
    \item[--] unikatową nazwę akcji, która jednoznacznie określa akcję w bazie danych;
    \item[--] opis akcji, który może być dowolnej długości;
    \item[--] czynność, z którą związana jest akcja.
\end{itemize}

\subsubsection[Proc\_Act]{Proc\_Act}
Relacja \texttt{proc\_act} przechowuje informacje o tym jakie akcje wchodzą w skład danych procedur. Relacja zawiera kolejno następujące atrybuty:
\begin{itemize}
    \item[--] identyfikator krotki, który jest kluczem publicznym relacji \texttt{proc\_act} i jest automatycznie generowany przez sekwencję \texttt{id\_proc\_act} po dodaniu krotki;
    \item[--] identyfikator akcji, który jest kluczem obcym z relacji \texttt{actions};
    \item[--] identyfikator procedury, który jest kluczem obcym z relacji \texttt{procedures}.
\end{itemize}


\subsection[Dodatkowe elementy bazy danych]{Dodatkowe elementy bazy danych}
W celu przyspieszenia procesu wyszukiwania i sortowania założono indeksy na następujących atrybutach:
\begin{itemize}
    \item[--] surname w relacji \texttt{userdata};
    \item[--] login w relacji \texttt{users};
    \item[--] name w relacji \texttt{actions};
    \item[--] name w relacji \texttt{procedures}.
\end{itemize}
Oprócz powyżej opisanych indeksów, system zarządzania bazą danych założył automatycznie indeksy na kluczach publicznych
wszystkich relacji bazy danych.
\newpage

\begin{center}
	\begin{figure}
	  \caption{Diagram UML}
	    \label{fig:Diagram}
	      \begin{center}
	        \includegraphics[scale=0.55]{Diagram.eps}
	      \end{center}
    \end{figure}
\end{center}

\section[Inne wymagania produktu]{Inne wymagania produktu}
\subsection[Wymagania stawiane systemowi]{Wymagania stawiane systemowi}
	Aplikacja będzie uruchamiana w systemie operacyjnym Windows Xp/Vista i w miarę możliwości w systemie Linux.
	Nie jest wymagana duża moc obliczeniowa maszyny, na której będzie uruchamiany program. Wymagane jest jednak połączenie z Internetem ze względnie dużą przepustowością. Wymagana jest zainstalowane oprogramowanie Java i PostgreSQL.
\subsection[Licencjonowanie i instalacja]{Licencjonowanie i instalacja}
	System pomimo swoich cech użytkowych nie będzie sprzedawany ani rozprowadzany. Projekt będzie zawierał kod źródłowy. Żeby uruchomić aplikacje należy najpierw skompilować kod i zainstalować aplikacje z pliku binarnego.
\subsection[Wymagania efektywnościowe]{Wymagania efektywnościowe}
	W aplikacji wymagane jest odbieranie i wysyłanie powiadomień w jak najszybszym czasie. Nie są również dopuszczalne jakiekolwiek nieobsłużenie czy zagubione wiadomości. Ważne jest, aby aplikacja mogła być uruchomiona bez przerwy.


\section[Wymagania dokumentacyjne]{Wymagania dokumentacyjne}
\subsection [Wymagania dokumentacyjne] {Wymagania dokumentacyjne}
	Dokumentacja powinna być prowadzona na bieżąco w trakcie pisania projektu. Wersje dokumentacji wraz z kodem powinny znajdować się w repozytorium kontroli wersji (SVN). Każdy z programistów powinien mieć dostęp do kodu. Trzeba wziąć po uwagę, że dokumentacja będzie dostępna dla użytkownika. Powinna zawierać informacje ułatwiające instalacje,  konfiguracje, jak i użytkowanie aplikacji.
\subsection[Pomoc on line]{Pomoc on line}
	W programie powinien być wbudowany system wysyłania informacji o błędach i problemach związanych z aplikacją. Powinna być też możliwość odbierania informacji od pomocy technicznej.
	
\section[Słownik pojęć]{Słownik pojęć}

\begin{description}
	\item[Czujnik] -- urządzanie lub program monitorujące stan systemu i automatycznie zgłaszające odstępstwa od normy.

	\item[Information Technology Infrastructure Library (ITIL)] -- zbiór zaleceń pomagający firmie w efektywnym świadczeniu usług informatycznych.

	\item[IT Service Continuity Management (ITSCM)] -- proces ITIL skupiający się na zapewnieniu ciągłości działania systemu poprzez efektywne reagowanie na pojawiające się sytuacje kryzysowe.

	\item[Procedura] -- zestaw zdarzeń, które należy wykonać w momencie wystąpienie sytuacji krytycznej.

	\item[Zdarzenie] -- pojedyncza akcja wykonywana przez system ITSCM.

\end{description}

\end{document} 